System and method for managing mobile workers

ABSTRACT

A system manages mobile workers and includes a plurality of clients and a server. A database includes a plurality of target objects that are classified corresponding to facilities assets to be worked on by a mobile worker and attributes of each target object, including any tasks to be performed on target objects. A rule engine determines algorithms based on a utility function for partitioned jobs wherein different algorithms are selected and used for different partitions to schedule jobs and mobile workers in selected different regions. An algorithm is selected based on a weighted sum that is calculated from a possible number of work schedules, jobs and mobile workers for each partition. A selected policy for a job environment determines how mobile workers, jobs and work schedules are partitioned. A plurality of system agents automate supervision.

RELATED APPLICATION(S)

This application is a continuation-in-part of U.S. patent applicationSer. No. 11/845,968 filed Aug. 28, 2007, which is a continuation of Ser.No. 09/656,393 filed Sep. 6, 2000, now U.S. Pat. No. 7,283,971 issuedOct. 16, 2007, the disclosures which are hereby incorporated byreference in their entirety.

FIELD OF THE INVENTION

This invention relates to facilities management, and more particularly,this invention relates to managing workers.

BACKGROUND OF THE INVENTION

Copending patent application Ser. No. 11/845,968 discloses a system andmethod for managing mobile workers. A plurality of clients eachcorrespond with a mobile worker to be managed. Each client includes acommunications device for receiving messages detailing work schedulesfor tasks to be performed as jobs on target objects in a jobenvironment. A server is in communication with each of the plurality ofclients. The server includes a database having a plurality of targetobjects that are classified corresponding to facilities assets to beworked on by a mobile worker, and attributes of each target object,including any tasks to be performed on target objects.

The server includes a rule engine operative for determining algorithmsbased on a utility function for partitioned jobs and mobile workers.Different algorithms are selected and used for different partitions toschedule jobs and mobile workers in selected different regions. Analgorithm is selected based on a weighted sum that is calculated from apossible number of work schedules, jobs and mobile workers for eachpartition. A selected policy for a job environment determines how mobileworkers, jobs and work schedules are partitioned. The server includes aplurality of system agents that automate supervision, including workplanning, scheduling, dispatching, stores management job statementmanagement and end-of-shift management. A communications device isoperative with the server for communicating calculated work schedulesand jobs as messages to the clients.

Some scheduling algorithms, such as a round robin and reschedulingalgorithm, are set forth. It is advantageous that some constraints couldbe used to direct a scheduling, (e.g., a rescheduling) algorithm.

SUMMARY OF THE INVENTION

A system manages mobile workers and includes a plurality of clients anda server in communication with a plurality of clients. The serverincludes a database having a plurality of target objects that areclassified corresponding to facilities assets to be worked on by amobile worker and attributes of each target object, including any tasksto be performed on target objects. A rule engine is operative with thescheduling algorithm to map from a problem space for partitioned jobsand mobile workers to a solution to schedule jobs and mobile workers inselected different regions. The rule engine is operative to control thescheduling algorithm using heuristics comprising at least one of a tabusearch, iterated local search, guided local search, and variableneighborhood search to focus a search space to regions for moving theschedules of high utility. A communications device is operative with theserver for communicating any determined schedules and jobs as messagesto clients.

These clients each include a communications device for receivingmessages detailing work schedules for tasks to be performed as jobs ontarget objects in a job environment. The server includes a databasehaving a plurality of target objects that are classified correspondingto facilities assets to be worked on by a mobile worker, and attributesof each target object, including any tasks to be performed on targetobjects.

A selected policy for a job environment determines how mobile workers,jobs, and work schedules are petitioned. The server includes a pluralityof system agents that automate supervision including work planning,scheduling, dispatching, storage management, job state management andend-of-ship manager. The rule engine is operative to control thescheduling algorithm using the heuristics.

In one aspect, the tabu search is operative to prevent searchingrecently explored portions of the search space. The iterated localsearch perturbates a solution for a new solution as a starting value foranother scheduling algorithm. The guided local search perturbates autility function to penalize sub-optimal components of a solution. Thevariable neighborhood search can perturate a neighborhood search to beused in the next iteration.

In another aspect, the scheduling algorithm is operative with numericaland combinatorial constrant objects allowing searching from a generalsearch to a more specific search. A constraint object can maintain timeusage of a constraint object.

The server can include a simulator database and simulation module thatqueries the simulation database to determine the effects of a policychange on planning and scheduling of jobs and workers using differentalgorithms and petitions and can include an event bus.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects, features and advantages will become apparent from thedetailed description which follows, when considered in light of theaccompanying drawings in which:

FIG. 1 illustrates a general overall block diagram of the system showingthe interconnection among the various components of the presentinvention.

FIG. 2 is a flow chart illustrating the scheduling agent.

FIG. 3 is a flow chart illustrating the job state manager agent used forcontrolling other system agents.

FIG. 4 is a flow chart illustrating the planner agent.

FIG. 5 is a flow chart illustrating the storage agent.

FIG. 6 is a flow chart illustrating an example of a job statetransition.

FIGS. 7-11 illustrate flow charts for Use Cases, which show theinteraction among human components and the computer.

FIG. 12 is a flow chart illustrating a clean up scheduling algorithm.

FIG. 13 is a flow chart illustrating a brute force scheduling algorithm.

FIG. 14 is a flow chart illustrating a rescheduling algorithm.

FIG. 15A illustrates a round robin scheduling algorithm.

FIG. 15B illustrates a maximal utility scheduling algorithm based onordering the unassigned job queue from highest to lowest utility.

FIG. 15C illustrates a maximal utility scheduling algorithm based onordering the unassigned queue from lowest to highest utility.

FIG. 16 illustrates the inter-relationship between the live andhistorical databases.

FIG. 17 is a block diagram illustrating the inter-relationship betweenthe policy database, the simulator, and the system agents.

FIG. 18 is a three-dimensional graph showing a surface that has severallocal maxima.

FIGS. 19A and 19B are examples of a search space with two exhaustivesearch techniques with a depth-first and breadth-first searching.

FIG. 20 is a graph showing a resource allocation profile in accordancewith a non-limiting example

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The embodiments will now be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. Other aspects may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein. Rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope to those skilled in the art. Like numbers refer to likeelements throughout.

For purposes of description, there follows an overview of the system,giving a high level description of basic components and theirinteraction. The system, in one aspect, is a web-based client/serverapplication developed to manage the activities of skilled mobile workers(FIG. 1). The server contains all information regarding work to be done,who will perform the work, and the rules (policies) governing theirimplementation and interactions. The system can be used on a hand-heldcomputer or PC workstation on a LAN. The system provides a remote workerwith all relevant task information via a full or part-timetelecommunications link, such as via a hand-held web based device.

For purposes of a non-limiting explanation of this system description,work is reduced into four major components:

1) Targets—Anything you aim to work on, e.g., a piece of equipment.

2) Tasks—The collection of actions to be taken, e.g., Task=ServiceAir-handler, Action=Lube Motor Bearing. Tasks have attributes such asskill required, estimated time, and material needed.

3) Workers—The human resources capable of completing the desired task.Workers have attributes such as skill, skill level (grade), scheduleavailability.

4) Jobs—Collections of tasks applied to targets and assigned to workers.

The different components of the system as described below can be definedand can operate on the principle of these four major relationships. Thesystem architecture provides a consistent set of application interfacesthat follow the natural process flows within each subsystem.

In accordance with one aspect, there are some basic foundationcomponents that are used to solve the common problems of a facilitiesmanagement domain.

The system is built on an implementation of a recognized numberingscheme. Many schemes can be used. AN example is the specification fromthe Construction Specifications Institute (CSI), which forms thefoundation for architectural drawings. This foundation is composed offour components, which are described as follows:

1) Master Format Classification—Classifies what something is. Forexample: An Indoor Air-handler unit is part of the Mechanical System; ispart of the Heating, Ventilating; and is part Air Conditioning EquipmentSubsystem; is part of the Air Handling Units Subsystem Group; and isdescribed as a Component called Indoor Air-handler. Thus, an IndoorAir-handler (or any piece of equipment) is classified for all facilitiesin the same manor. This completely removes any ambiguity relative todescribing things that will be managed by the system.

2) Data Definition—Describes generically what attributes a classifiedobject will have. It includes such things as Design Data (how it isexpected to perform), Generic Manufacturing Data Form (make, model,etc.). For example: An Indoor Air-handler will have Design Data such asCFM, coil type/size, motor type/size, etc. This is also where externaldata requirements, such as OSHA requirements, are recorded.Additionally, this is where Tasks are defined. Tasks are a finite set ofactions, based upon target classification. The system of the presentinvention provides a complete set of tasks for a given classification,and provides the facilities for any users to add more as desired. DataDefinitions make up one component of Policy as described below.

3) Data Specification—This is where specific data about a particularIndoor Air-handler is recorded through the system interface. Forexample: Air-Handler #20 is in Building One, Floor 10, Room 1015. It issupposed to produce 10,000 CFM, has a 2 pass chilled water coil, it hasa 15 horsepower motor, it has a GE Motor Model number 15 CCM, 230 volts,3 phase. The data requirements have already been defined, so the userneed only populate the “templates” provided. A user may add more dataelements as desired.

4) Process Knowledge—The system of the present invention has embeddedthe process knowledge used in the basic supervisory functions for workmanagement, including: Planning, Scheduling, Dispatching, StoresManagement, Project Management, and Supervision (called Job StateManagement), and others. Process knowledge is the ability to makespecific decisions relative to the function being managed. For example:When the Planner is deciding if a Task is due to be run, it must firstdetermine the last time it was run and evaluate whether or not enoughtime has elapsed to make it eligible to be planned (used in a job). Thesystem makes the link between the definition, the data, and the businesslogic needed to automate the decision making process.

The system product, built on the above foundational components, enablescustomers that use the invention to execute a continuous loop ofoperational improvements. This loop has three aspects to it: (1)Process; (2) Policy; and (3) Prediction Through Simulation as shown inFIG. 17. Those three aspects can be explained as follows:

I. Process

The system defines process as the collective system activities thatcover all aspects of worker management. It begins with asystem-generated request for work (planning), and ends when a Job iscompleted. This involves, among other things, moving a Job (a collectionof tasks for a target) through various states (points in its life-cycle)until it is completed. When a job has been created by the system it hasa state called a Pending Job Order (PJO). The system evaluates allpolicies and, if policies are satisfied, moves the job in a job statetransition to the next state, called Ready for Scheduling (RFS). Forexample, if a policy contained within a policy database on the serversays that a job cannot be RFS unless the earliest start date is equal toor greater than today (the date of the evaluation), then the job is notmoved to RFS. If that condition and all other conditions related to theSTATE RFS are met, then the job is moved to RFS. That Process, and allothers, are completely controlled by Policy contained in a policydatabase and implemented by system agents.

II. Policy

The system defines Policy as all of the definitions, rules, and businessfactors that control the behavior of the different system agents, whichin turn, controls the managed workers. Examples of three types of policyelements include:

A. Definitions—If the tasks defined for a particular target are changed,then the mobile worker is affected. If the frequency for a task ischanged from monthly to weekly, then the demand for labor resources isincreased.

B. Rules—If the system is planning for tasks with a frequency ofquarterly, then the system also plans for all frequencies less than that(monthly, weekly, etc.).

C. Business Factors—These elements directly affect how workers arescheduled, and how costs are accounted for. If a level five electricianis doing level three work, then the system tracks the “skill premium,”i.e., the difference paid between the minimal skill required vs. theactual skill delivered. By adjusting the weight of this type of factor,users can minimize negative costs by weighting a given factor heavily.That will force the system to minimize skill premium occurrences.

III. Prediction through Simulation

The system includes an intelligent work management simulator thatprovides management the capability to visualize the effect of proposedchanges in business policy (work force usage, energy management, storesetc.) on business indicators, such as labor costs and energy savings.After policy values have been (temporarily) changed, planning andscheduling may be run and the results examined. Then, the work force'sresponse to these scheduled tasks is estimated, based on theircharacteristics (workers, tasks, and their interdependencies). Theseresults are then translated into business-meaningful knowledge that themanager can use to determine whether the proposed new policy valuesshould be accepted, modified or rejected.

System Agents

An example embodiment uses a plurality of system agents to automatesupervision, which includes work planning, scheduling, dispatching,stores management, job state management, and end-of-shift management.These system agents provide computer representations of functionsnormally fulfilled by people in an organization. The agents behavior isbased on policy. This characteristic makes the agents totallyconfigurable in user-customized ways. Management then has the ability toinstantaneously respond to changing conditions, and maximize workerproductivity with the assurance that policy decisions are implementedthe same way each and every time.

A planner agent inventories all items requiring work, and determines thetasks to schedule, the skills required to complete the tasks, andmaterial needed. For example, it looks at equipment records to determinewhich ones are due for service. The planner agent usescustomer-established policy to decide if all criteria (such as time,cycles, etc.) have been met. When management's rules determine that thecriteria were met, the agent creates a job.

A schedule agent matches skill resources with the demands of the job andcreates a proposed schedule. The rules governing this agent concern theissues of location, skills, time needed, and similar requirements. Oncethis agent's evaluation is complete, the job is placed on a worker'sschedule for further processing.

A dispatcher agent is responsible for tracking the location and statusof the workforce. When orders are added to a resource's schedule, thedispatcher agent will determine, based upon priority rules, if theworker should be interrupted or be allowed to finish the currentassignment. In addition, the dispatcher “knows” what methods to use tocontact the worker. For example, if the worker's handheld computer doesnot respond to messages, the agent may then call the pager number.

A job state manager agent maintains the state of all active jobs. Whensystem events occur, this agent evaluates rules determining which jobs,if any, should transition to a new state, and what the new state of eachjob is. For example, when the scheduler finishes running, scheduled jobsare typically transitioned out of Request For Scheduling (RFS) to one ofthe post-scheduling states, such as scheduled pending dispatch (SPD).

A stores agent is responsible for making sure the necessary materialsrequired for a job are available. If the materials are not available,the store's agent will notify an operator that a purchase must be madein order to complete the job. The store's agent will continue to checkfor the availability of the material and, when it arrives, allow the jobto be scheduled.

An end-of-shift agent evaluates all jobs that were placed on workschedules and not completed. For example, it will determine (among otherfactors), based on Policy, whether or not to give the job to anotherworker or reschedule the job to the same worker the next time thatworker is on shift.

A project manager agent coordinates the flow of a project, which isdefined as two or more jobs created for related purposes. For example:Project=Move Wall; Jobs include: 1) Disconnect Electric, 2) RemoveDrywall & Studs, 3) Repair Flooring. Each may require a different skill,and may require sequential execution. In this example, the projectmanager agent will ensure that Job 1is completed before Job 2 can bescheduled. This agent will facilitate management of sophisticatedinter-job dependencies.

Other agents can also be included as necessary for system operation.Other policy agents can be used for performing tasks as required bythose skilled in the art.

Business viewers are used as a portal into the system and allows usersto follow a chronological flow in the system from the perspective oftargets, workers jobs or agents. For example: To answer the question,“What did the Scheduler Agent do yesterday?”, users will be able toselect an Agent tab of a graphical user interface (GUI), the date, and“drill down” to find all the activities the agent performed and what theresults were for that agent. In the case of the scheduler, a user couldfind out how many times the scheduler ran, how many jobs the schedulerevaluated, how many schedules were created, and how well those schedulescan be rated for overall effectiveness (called utility).

All of the database changes made by the system Use Cases (userinteractions with the system) and system Agents are reflected in adatabase system known as the intelligent work management historydatabase. This data warehouse will be navigated by using businessviewers. Users can view summary information about a whole class oftargets (types based upon Master Format Classification), or informationabout individual targets (objects). These tools may also be used toproduce historical reports for any date/time period. These tools are theprimary means of viewing the historical performance of the workforce.

A user may navigate the web of business objects, going from class toclass or object to object, following the natural business associationsreflected in the data (e.g., a worker has a work schedule, the workschedule has jobs, each job has job tasks, each task is for a target).This can be referred to as the “space” the objects live in. Thenavigation tools (business viewers) also allow the user to move aroundin time and space, navigating the historical operation of the workforce, producing reports focused on the space and time slice in whichthey are interested.

One embodiment is especially advantageous because it allows simulationof facilities management by copying the live database for simulation.The simulator provides management the capability to visualize the effectof proposed changes in business policy (work force usage, energymanagement, stores etc.) on business indicators, such as labor costs andenergy savings. After policy values have been (temporarily) changed,planning and scheduling may be run and the results examined. The workforce's response to these scheduled tasks is estimated, based on theircharacteristics (workers, tasks, and their interdependencies). Theseresults are translated into business-meaningful knowledge that themanager can use to determine whether the proposed new policy valuesshould be accepted, modified or rejected.

Using the simulator does not change the value of any policy data in the“live” system. That is, the live system continues to run unaffected byany changes made in the simulation database. To effect this, the livedata is copied into a simulation database when the simulator starts.Caching techniques are used to predefine the table headers, to make thesimulation start up procedure timely.

The typical use of the simulator is to determine the effects of a policychange on the results of planning and scheduling. Although the patternof use can vary, one pattern can operate as follows:

1. Set the values of one or two rules or factors (differential test ofthe value of that rule/factor(s).

2. Run the planning and scheduling agents. (This includes running thesimulated worker schedules to completion for each shift.)

3. Use the business viewers to examine the differential impact of thenew policy settings.

4. If the new settings are not acceptable return to step 1.

5. Persist the final policy settings to the live system (optional).

6. Exit the simulator.

Other uses would include:

a) Differential setting of a business object, such as an attribute of atask or a target definition and simulation of the direct effect ofplanning and scheduling with the new settings.

b) Adding a worker or a target and examining the effect of planning andscheduling with the new worker or target.

c) Major changes, such as adding a third shift of workers.

The Simulator can display a screen that is used to control thesimulation process. The actual inspection of results is explained in thefollowing section, “viewing simulations”. The simulation use casepresents one screen with a number of choices for the user. The user isprompted to name the simulation and provide a description of its raisond'être, and is provided with the following capabilities:

1. Simulate X days agent processes. This includes the following:

a) Run the Planner. The planner is run in the simulated world, followedby the job state manager.

b) Run the scheduler and the scheduled jobs. For each shift during theplanning horizon.

c) Jobs are scheduled.

d) The job state manager is run to transition the job state.

e) Dispatchable jobs are “run.” The worker simulation agent determinesthe disposition of each scheduled job.

f) The project manager is run to prepare the jobs that are now eligibleto be run.

g) The end of shift agent is run to determine the fate of any unfinishedjobs (if any).

h) The start of shift agent is run to prepare the initial work schedulesfor the next shift.

2. Reinitialize. Rolls back the registry and all jobs to their initialstate (that is, as they were at the beginning of the simulation).

The following steps three (3) and four (4) are not necessary steps, butcould be followed.

3. Roll back planned and scheduled work. All jobs created by the plannerare removed. All jobs that existed at the beginning of the simulationare returned to their initial state. Similar to “reinitialize” exceptall changes to the registry are preserved.

4. Persist the registry. Normally, all changes made in the simulationare invisible in other simulations or the “real world”. This commandallows the user to propagate all registry changes from the simulatedworld to the real world.

5. End the simulation. The simulation will be captured as a cluster ofdatabase records, for post-simulation viewing with the Business Viewers.

The Business Viewers are the main tool used to view the results of thesimulations. The Business Viewers do not distinguish between the livesystem and simulated worlds. Instead, the run on the appropriatedatabase and report results accordingly. A user may open N windows, eachof which may point at a time and location in any world. This allowsusers to view one or more time points in a given simulation, compare twosimulations or a simulation and the real world, and so forth.

Future plug-ins into the log viewer will allow a context-basedcomparison of results. The delta in the registries for two worlds willbe displayed along side the comparison of values in corresponding lognodes for the two worlds.

Referring now to FIG. 1 there is illustrated an overview of thearchitecture and showing a facility at block 100 with various types ofuser operating stations that interconnect to the server 102 via atelecommunications link, such as the worldwide web of the internet. Themobile operators use hand-hand mobile devices 104, workstations 106 andother browser platforms 108, which interconnect such as by atelecommunications link, with the server 102 and its various components,which communicate via an event bus 110. The basic components of thesystem include a plurality of system agents 112 as described above,business viewers 114 that are coupled with one business viewerapplication and a plurality of Use Cases 116 that define userinteraction with the computer. The system agents 112, business viewers114 and Use Cases 116 are interoperative with live and historicaldatabases 120, 122. The system agents and Use Cases also interact withthe event bus, which also interacts with a rule engine 124 that isstored as a program within the server. The event bus also interacts witha logger 126 and log viewer 128, which both interact with the logdatabase 130.

FIG. 2 illustrates the basic flow chart of the scheduler system agent.As identified, at block 200, jobs are petitioned into buckets based onsuch attributes as the job's location and skill requirements.Multi-worker jobs are scheduled for each bucket (block 202) and singleworker jobs are scheduled for each bucket (block 204). Worker schedulesare updated (block 206) and for each location, an event is issued if anyjobs were scheduled (block 210).

The algorithms and parameters to use are determined when themulti-workers and single workers are scheduled (block 212). At thispoint, it is possible to gather job and worker statistics (block 214),and then run a scheduler rule engine that outputs the algorithm andparameters to be used to schedule that set of jobs to those workers(block 216). After the algorithms are determined, the algorithms are runusing the output parameters (block 218). An ordered set of algorithms torun are determined (block 220), and for each algorithm to be run, it isset in the indicated order (block 222).

FIG. 3 illustrates a job state manager agent. As illustrated, the jobstate manager will gather all “live” jobs (non-terminated) where thedifferent states that are incoming are noted at (block 230). Theunsatisfied procedures are determined for each job (block 232). New jobstates are determined (block 234). At this time, the job state managerrule engine is run and the outputs equal the new states (block 236). Adetermination is then made whether a new state equals the old state(block 238). If it is not, then the new state is set in the job (block240), and the rule engine runs again. If the new state equals the oldstate, then a determination is made whether a new state is the incomingstate (block 242). If it is not, then a HASH function for the job andstate is run (block 244). If the new state is the incoming state, thenthe system is done (block 246), and the job states are updated in thedatabase (block 248). An event is issued for each new state (block 250).

The planner agent is illustrated in FIG. 4. Tasks are gathered for alltargets (block 260). The tasks are petitioned into schedule groups(block 262) and the intertask dependencies are determined (block 264).The schedule groups are determined (block 266) and a subroutine run todetermine the schedule group (block 268). In the subroutine, theschedule of group parameters are gathered (block 270), and the plannerrules are run through the rule engine (block 272). Outputs of the ruleengine include, for example, the job's priority and the job's earliestand latest start dates (block 274). Jobs are built and assigned aninitial state (block 276).

A storage agent is shown in FIG. 5 and illustrates the process flow fordetermining inventory and the stores. A parts request is first made(block 300) and a request evaluated (block 302). Permissions aredetermined (block 304). A determination is then made whether it is astock item (block 306) or a non-stock item (block 308). The currentstock is evaluated if it is a stock item (block 310). At this time, ifthe current stock has been evaluated, the system determines if there isa verified stock request (block 312). If there is, a process stockrequest is run (block 314) and stock issued (block 316). The systemfollows a series of steps for loading (block 318), picking and issuing(blocks 320 and 322), and verifying and checking the records andreordering activity (blocks 324, 326, and 328). This also occurs ifafter the current stock is evaluated, there is not any stock. After thereorder activity, a parts order is requested (block 330) and the sourcesare evaluated (block 332). This occurs at the evaluate request, when anon-stock item is determined and the stock determination is made with aninventory recommendation (blocks 338 and 340). After sources areevaluated, vendor products are determined (block 342) and procurementactivities arranged (block 344). The completed requisition occurs (block346) with a receiving report and purchase report (blocks 348 and 350).The order status can be monitored (block 352). At the time of acompleted requisition, there is a receive and delivery (block 354) withparts rejected (block 356) and parts received (block 358). If parts arereceived, there is an acceptance (block 362), and possibly, a rejection(block 364), and if not, then a validation (block 366) with an entryinto stores (block 368). If it is a new store item (block 370), then thedisposition is determined (block 371) and there is a disposed item(block 372), non-stock issued (block 374), a stock issued (block 376),or stock (block 378).

The job state manager agent is the component that makes all statechanges in all live jobs. Every job has a state. The job begins in aninitial state, as shown in the Job State Transition diagram of FIG. 6.The job begins as an initial state (null state) and looks for proceedswith the waiting for proceeds block. The sequence of job starts isdetermined by the job state manager's rule set. The job state managerruns the rule engine to determine when to make a transition fordifferent customers and can arrange the state with different orders andmake transitions at different times. A typical sequence of job statetransitions is as follows: the initial job for a job that has precedingjobs is “waiting for proceeds.” This is generally followed by “waitingfor stores” (WFS) as the next step, and then once stores are assigned,the job becomes a pending job order. These and other state transitionsare shown in the job transition diagram of FIG. 6. This diagram showsthe default flow of job states, but individual users can configure jobstate transitions based on user defined rules and policies.

FIGS. 7-11 show various Use Cases where task definitions can bemaintained in FIG. 7, and in FIG. B, the policy definition can bemaintained. In FIG. 9, the target definitions are maintained anddefined, and in FIG. 10, various worker location information ismaintained. In FIG. 11, the targets are maintained. These flow chartsshow the interaction among computer and user and how definitions andother uses are maintained and selected. FIGS. 12-15 show flow charts forvarious algorithms.

The clean up scheduling algorithm is set forth in FIG. 12 where eachwork schedule is examined (block 500). For each job on each schedule(block 502), a determination is made whether the changing utility isless than zero (block 504), and if yes, then the job is dumped back tothe unscheduled job queue (block 506). If the changing utility is notless than zero, then the loop starts again.

FIG. 13 shows the basic high level flow chart of the group used for thescheduling algorithm. The maximum number of jobs possible on a scheduleequal to n is determined (block 508). All combinations of up to n jobsare tried on each schedule, noting the total scheduled utility (block510). Assignments are chosen that maximize the total scheduled utility(block 512).

The basic concept of the rescheduling algorithm is shown in block formatin FIG. 14. The unassigned job queue is ordered from the highest utilityto the lowest utility (block 520). For each schedule, the systemsubstitutes the unassigned job for the lowest utility job whose removalleaves space for the unassigned job (block 522). The unassigned job isassigned to the work schedule it adds the greatest utility (block 524).The system determines whether to do double replacements (block 526). Ifthere are no double replacements, then the system is done (block 528).If double replacements are desired, then for each schedule, anunassigned job is substituted for two lowest utility jobs whose removalleaves space for the unassigned job (block 530). Unassigned jobs areassigned to the work schedule and adds the greatest utility (block 532).

The primary robin scheduling algorithm is shown in FIGS. 15A-15C. Asshown in FIG. 15A in the round robin scheduling algorithm, theunassigned job queue is ordered from the highest utility to the lowestutility (block 540) and then the jobs assigned to the workerssequentially (block 542). FIG. 15B illustrates the utility increasingscheduling algorithm, where the unassigned job queue is ordered from thehighest utility to the lowest utility (block 544) and each job isassigned to the schedule to which it adds the greatest delta utility(block 546). FIG. 15C shows the utility decreasing scheduling algorithm.The unassigned job queue is ordered from the lowest utility to thehighest utility to the highest (block 548). For each job schedule, it isassigned to the work schedule for which it adds the greatest deltautility (block 550).

FIG. 6 illustrates the interrelation between the live and historicaldatabases. The live database holds the stored data and uses triggers andstored procedures to create a “create” record, which is recorded in ahistorical database. Updated records and deleted records are also storedin the historical database 562 as “update” records and “delete” records.

FIG. 17, as explained before, shows a general high level overview of thesimulator program. Policy values are set in the simulator (block 570)and the simulator run (block 572). The information obtained is used toset policy values in the live system (block 574).

There now follows a general, high level description of the schedulingprocess.

For scheduling jobs, the attributes of the problem are used, such aslocation and skill, to partition the set of jobs and the workers. As aresult, the system has several smaller problems to solve. Assumedly,each of the smaller problems is easier to solve than the original largerproblem. An example of a partition would be one responsible forscheduling all the electric jobs on a location to the electricians atthat location.

For each partition, the system uses a different algorithm to schedulethe jobs in that partition to the workers in that partition. Forexample, the system can try an exhaustive try-all-combinations approach.This might be the best algorithm to use if, for example, there are 1 or2 workers and perhaps a couple jobs, for example, the plumbers at alocation. Other algorithms may prove to be more appropriate forpartitions with more jobs and workers.

Partitioning is a process of taking a problem space and dividing it into“regions.” In this case, the regions would be defined by the number ofworkers and the number of jobs for that region. An example might be allthe electricians and all the electric jobs at one site. Partitioningresults in the assignment of an algorithm and a set of “parameters” toeach region. These algorithms are then used to schedule each partition.The result of this activity is a set of schedules for all the jobs andall the work schedules.

Part of this process is a classification problem. This is the assignmentof algorithms and parameters to each partition. In support of thiseffort, experiments were run to determine how well various algorithmsrun under different parameterizations in different regions of theproblem space. For example, for some of these algorithms, usingdifferent utility functions lead to different results. The utilityfunction is thus one of the parameters that would be set for analgorithm, based on the characteristics of the problem space for thatpartition. The idea is to determine which parameter settings are usefulin which regions for which algorithms.

The schedule agent treats each (location, skill) combination as aseparate (partitioned) problem. It solves this problem using a set ofalgorithms and parameters that is tailored to the characteristics ofthat (location, skill) partition, such as the number of workers and thenumber of tasks for that location and skill.

The scheduler uses the a rule engine to determine the algorithms andparameters used for the particular characteristics of the location andskill partition. Inputs to the rule engine include characteristics ofthe partition, as well as system- and policy-level information. Outputsinclude the selection of algorithms and parameters (e.g., k-value) to beused for this location and skill.

The high level scheduling algorithm is thus as follows:

Given: A set of workers with their work schedules either empty or withjobs assigned. A set of jobs, some of which may have already beenassigned to the above work schedules.

Produce: An assignment of jobs to work schedules such that all the hardconstraints are satisfied for each work schedule. The soft constraintsare optimized, based on the average goodness of fit of the schedules.

Algorithm:

1. Use the constraints on jobs being “admissible” for schedules topartition the problem space into regions.

2. Use the rule engine to determine the algorithm and parameters to beused to schedule work of each partition.

3. For each partition, use the rule engine designated algorithm toassign jobs to work schedules for that region.

4. Combine and persist results.

There now follows a general, high level example of utility calculationand examples of their use. Naturally, the following description hasnon-limiting examples that assist comprehension, but are no meanslimiting.

Each job adds a certain amount of “delta utility” or “marginal utility”to a workers schedule. This is just the overall utility of the workschedule minus the utility of the work schedule consisting of the sametasks minus the job in question. Note that, due to non-linearities inthe utility computation (e.g., the effect of non-productive time) themarginal utility of a job will differ from worker to worker. Some of thescheduling algorithms take advantage of this fact during theiroperation: they tend to assign jobs to the work schedule for which theymake the most positive marginal utility contribution.

The scheduling process for a (location, skill) may consist of the use ofseveral algorithms, including a primary algorithm, an optimizingalgorithm, and a trim algorithm. These are shown below:

Primary Pass: Attempted to assign each free task to a work schedule withreplacement of lower utility tasks weighted sum with k=0.7 Penalizing:grade changes, NPT.

Trim Pass: Remove tasks of negative delta utility from work schedules.Weighted sum with k=0.4 Penalizing: grade changes, NPT.

Primary Pass attempt to assign each free task to a work schedule withreplacement of lower utility tasks. This is a description of thealgorithm used during the primary pass. The primary pass is used to“fill up” the work schedules with a first approximation of the jobassignments leading to maximal utility for these workers.

Weighted sum with k=0.7 Penalizing: grade changes, NPT. This is adescription of the utility function used for this algorithm. The utilityfunction in this case is a (weighted) sum of the time on schedule andthe prioritized time on schedule. The “k” value is used to mix these twovalues into the “raw” utility. This raw utility is then modulated by thepenalty factors; in this case, ones for grade changes (working undergrade level) and non-productive time (NPT).

Optimizing Pass: Attempted to assign each free task to a work schedulewith replacement of lower utility tasks. When included, the optimizingpass is an attempt to take high priority jobs on the unassigned jobqueue (UJQ) and assign them to workers. This sometimes includesdisplacing tasks that were assigned to the worker during the primarypass, as the assignment of jobs from the UJQ (with displacing, orreplacing, tasks) raises the overall utility of the worker's schedule.

Trim Pass: Remove tasks of negative delta utility from work schedules.This is a description of the algorithm used during the trim pass. Thetrim pass is used to “touch up” work schedules, typically by removingjobs/tasks of negative or very small utility from worker's schedules.

A log file is produced by the system scheduling agent. Each log recordcontains a final summary near the very end. A typical log record as anon-limiting example that could be used follows:

1) Summary Statistics: 8 workers, 24 tasks

2) Average Utility=26.1798%

3) System Parameters:

a) Workers may switch buildings

4) Factor Analysis:

5) Average factor due to usage over grade=0.981538

6) Average factor due to non-productive time=0.979904

7) Costing Analysis:

8) Total cost of Burdened labor=$628.2

9) Minimal labor costs=$624.2 (99.3633%)

10) Excess labor costs=$4 (0.63674%)

11) Excess labor costs due to usage over grade (2.5 hrs)=$4 (0.63674%)

12) Wasted labor costs=$412.2 (65.616%)

13) Wasted labor costs due to non-productive time (0.85 hrs)=$8.35(1.32919%)

14) Wasted labor costs due to idle time (45.35 hrs) =$403.85 (64.2869%)

15) Nominal Labor cost per hour=$8.94872

16) Minimal Labor cost per productive hour=$8.83333

17) Labor cost per productive hour=$26.175

There now follows a description of this log on a line-by-line basis.

1) Summary Statistics: 8 workers, 24 tasks—This line describes thenumber of workers and tasks in the partition (one location for oneskill).

2) Average Utility=26.1798%—This is the arithmetic mean (the average) ofthe utilities of the workers in the partition. Utility values range from0% to 100%.

3) System Parameters—There are several policy level constants thateffect the scheduling process.

3a) Workers may switch buildings—One of these is whether workers mayincur NPT by having jobs in more than one building in the location.

4) Factor Analysis—The utility value is computed by multiplying the“raw” utility (measure of time and priority on work schedules) by a setof business-meaningful factors. Each factor consists of a multiplierbetween 0 and 1, which is further moderated by a policy-level constant,which measures the “importance” of the factor to the business. Theseconstants are values between 0 and 1 that are used to attenuate theeffect of the factor.

Factors contribute to excess labor (work that could be done by lessexpensive labor) and to wasted labor (time on a work schedule that couldbe used for productive work instead). These are both illustrated below.

5) Average factor due to usage over grade—This factor measures theexcess labor penalty due to a worker being tasked for a job whose skillrequirement is lower than that of the worker. A lower skill worker coulddo the same job, at lower overall cost to the business.

6) Average factor due to non-productive time—This factor measures thewasted labor penalty due to a worker incurring non-productive time, suchas the time required to transport the worker between buildings if hiswork schedule includes jobs in more than one building at the location.

7) Costing Analysis—This section provides an analysis of the cost oflabor and the minimal cost of labor for the jobs assigned to theseworkers.

The cost numbers below are the total for all workers that have beenscheduled for the skill at the location. The costs per hour and perproductive hour are the average for all workers that have been scheduledfor the skill at the location.

8) Total cost of Burdened labor=$628.2—This is the total labor costs,based on the time on schedule for each worker and their correspondinglabor rate.

9) Minimal labor costs—This is the total labor costs minus the costs forexcess labor.

10) Excess labor costs—This is the cost for excess labor. In Versionminus one, this is due to usage over grade.

11) Excess labor costs due to usage over grade—This is the cost of usingthe assigned worker for a task where a lower grade worker is acceptable,minus the cost of using that lower grade worker. It is an avoidable,excess cost due to non-ideal scheduling.

12) Wasted labor costs—This is the cost of idle and non-productive time.

13) Wasted labor costs due to non-productive time—This is the cost oflabor for the hour(s) of non-productive time, such as the time it takesto transport the worker between buildings if he has jobs on his workschedule for more than one building at the location.

14) Wasted labor costs due to idle time—This is the cost of labor forthe hour(s) the worker is not tasked.

15) Nominal Labor cost per hour—This is the cost of labor minus the costof excess labor divided by the number of productive hours.

16) Minimal Labor cost per productive hour—This is the cost of theproductive time on the worker's schedule (i.e., the labor without anynon-productive time and using the minimal acceptable skilled worker foreach job on the work schedule) divided by the amount of productive time.

17) Labor cost per productive hour—This is the cost of the hours on thework schedule (at the worker's nominal rate) divided by the amount ofproductive time.

There are several times in the log that the unassigned job/task queue(UJQ) may be shown. This includes at the beginning of the schedulingrun, after each algorithm is applied, and after the final statistics. Atypical display could include the following:

1 Unassigned Task: Task task12 pri=2 time=150 bldg=2 level=3

1 Unassigned Task: This is the total number of jobs/tasks on the UJQ atthis time in the scheduling process.

Task task12 pri=2 time=150 bldg=2 level=3: This the task name, followedby the priority, time (in hundredth's of hours) and skill levelrequired.

There are several times in the log that the worker schedule summary maybe shown. This includes at the beginning of the scheduling run, aftereach algorithm is applied, and after the final statistics. A typicalworker schedule summary log record could be as follows:

1) Assignments for Fred (time=870 bldg=1 skill=5)

2) Utility=54.1696%

3) Factor due to usage over grade=0.889231

4) Factor due to non-productive time=0.916923 (0.6 hours)

5) Costing Analysis:

6) Nominal cost per hour=$11

7) Cost per productive hour=$14.7231

8) Minimal cost per productive hour=$10.3846

9) Total cost of Burdened labor=$95.7

10) Minimal cost of Labor (utility=1)=$67.5 (70.5329%)

11) Excess labor costs=$4 (4.17973%)

12) Excess labor costs due to usage over grade (2.5 hrs)32 $4 (4.17973%)

13) Wasted labor costs=$24.2 (25.2874%)

14) Wasted labor costs due to non-productive time (0.6 hrs)=$6.6(6.89655%)

15) Wasted labor costs due to idle time (1.6 hrs)=$17.6 (18.3908%)

There now follows a detailed analysis for each line.

1) Assignments for Fred (time=870 bldg=1 skill=5)—This shows the numberof jobs/tasks for this worker, the worker name, the time on the worker'sschedule (in hundredths of hours), the building the worker is nominallyin, and the worker's skill level.

2) Utility=54.1696%—This is a measure of the “goodness of the worker'sschedule. It considers the time on schedule, the priority of jobs, theamount of non-productive and excess time on the schedule, and otherfactors that measure the schedule's economic value. Utility values rangefrom 0% to 100%.

3) Factor due to usage over grade—This factor measures the excess laborpenalty due to the worker being tasked for a job whose skill requirementis lower than that of the worker. A lower skill worker could do the samejob, at lower overall cost to the business.

4) Factor due to non-productive time—This factor measures the wastedlabor penalty due to the worker incurring non-productive time, such asthe time required to transport the worker between buildings if his workschedule includes jobs in more than one building at the location.

5) Costing Analysis—This section provides an analysis of the cost oflabor and the minimal cost of labor for the jobs assigned to the worker.

6) Nominal cost per hour—This is the cost of labor for the worker'sschedule minus the cost of excess labor divided by the number ofproductive hours on the schedule.

7) Cost per productive hour—This is the cost of the hours on the workschedule (at the worker's nominal rate) divided by the amount ofproductive time.

8) Minimal cost per productive hour—This is the cost of the productivetime on the worker's schedule (i.e., the labor without anynon-productive time and using the minimal acceptable skilled worker foreach job on the work schedule) divided by the amount of productive time.

9) Total cost of Burdened labor=$628.2—This is the total labor costs,based on the time on schedule for each worker and their correspondinglabor rate.

10) Minimal cost of Labor (utility=1)—This is the total labor costsminus the costs for excess labor.

11) Excess labor costs—This is the cost for excess labor. In versionminus one, this is due to usage over grade.

12) Excess labor costs due to usage over grade—This is the cost of usingthe assigned worker for a task where a lower grade worker is acceptable,minus the cost of using that lower grade worker. It is an avoidable,excess cost due to non-ideal scheduling.

13) Wasted labor costs—This is the cost of idle and non-productive time(NPT).

14) Wasted labor costs due to non-productive time—This is the cost oflabor for the hour(s) of non-productive time, such as the time it takesto transport the worker between buildings if he has jobs on his workschedule for more than one building at the location.

15) Wasted labor costs due to idle time—This is the cost of labor forthe hour(s) the worker is not tasked.

The individual work schedule detail tasking may be appended to theindividual work schedule's summary information. The format is asfollows:

Task task211 pri=3 time=50 bldg=1 level=4 Delta utility=0.0361758—Thisshows the job/task name, the priority value, the time required (inhundredths of hours), the building the task is in, the skill levelrequired and the marginal utility for the job/task (see below).

The optimization process may optionally be shown “in action” asdisplayed below:

Beginning optimization pass with replacement of lower utility tasks

Starting next optimization pass over free task list

1) Work Schedule for Fred: adding task99983

-   -   removing task911    -   (0.0229544)

2) Work Schedule for Fred: adding task99993

-   -   removing task2142    -   (0.0398817)

3) Work Schedule for John: adding task99989

-   -   removing task812    -   (0.00637209)

4) Work Schedule for Marlene: adding task911

-   -   removing task1    -   removing task2    -   (0.046)

Starting next optimization pass over free task list

Optimization Pass Done

Optimizing Pass: Attempted to assign each free task to a work schedulewith replacement of lower utility tasks—weighted sum with k=0.8Penalizing: grade changes, NPT

Trim Pass: Remove tasks of negative delta utility from workschedules—weighted sum with k=0.5 Penalizing: grade changes, NPT

The last two items are the display of the algorithms and utilityfunctions used for the optimizing pass and the trim pass. These are thesame displays described above. The rest of this section will describethe unique outputs from the optimization pass, typically run during therescheduling process.

Beginning optimization pass with replacement of lower utility tasks—Thisis the delimiter for the beginning of the details of the optimizationpass.

Optimization Pass Done—This is the delimiter for the end of the detailsof the optimization pass.

Starting next optimization pass over free task list—This is shown at thebeginning of each sweep over the UJO. Some of the algorithms used in theoptimization pass continue to run until a sweep results in no changes tothe work schedules and the UJQ.

Work Schedule for Fred: adding task99983—This shows a task being addedonto a work schedule.

removing task911 This shows a task being removed as part of the actionof adding the task shown above.

(0.0229544)—This shows the marginal utility of the actions: The utilityof Fred's schedule is now 0.0229544 higher than it was before this swapof tasks.

Work Schedule for Fred: adding task99993

-   -   removing task2142    -   (0.0398817)

Work Schedule for John: adding task99989

-   -   removing task812    -   (0.00637209)

Two more examples of tasks being substituted on a work schedule.

Work Schedule for Marlene: adding task911

-   -   removing task1    -   removing task2    -   (0.046)

Here the task that was removed from Fred's schedule is added toMarlene's schedule, in place of two shorter tasks. This is known in thesystem of the present invention circles as the “hopscotch effect.”

An example of the determination of grade factors and non-productive timefollows. Consider a schedule with the following assignments to oneworker:

Assignments for Fred (time=870 bldg=1 skill=5)utility=0.206842Factor due to usage over grade=0.28Factor due to non-productive time =0.90875 (0.1 hours)

Costing Analysis:

Nominal cost per hour=$11Cost per productive hour=$16.925Total cost of Burdened labor=$135.4Minimal cost of Labor (utility=1)=$95.7 (70.6795%)Excess labor costs=$39.7 (29.3205%)Excess labor costs due to non-productive time (0.1 hrs)=$1.1 (0.812408%)Excess labor costs due to idle time (0.6 hrs)=$6.6 (4.87445%)Excess labor costs due to usage over grade (8 hrs)=$32 (23.6337%)Task task2 pri=3 time=50 bldg=1 level=1 Delta utility=0.012876Task task1 pri=3 time=50 bldg=1 level=1 Delta utility=0.012876Task task42 pri=4 time=50 bldg=1 level=1 Delta utility=0.0144659Task task41 pri=4 time=50 bldg=1 level=1 Delta utility=0.0144659Task task12 pri=2 time=150 bldg=2 level=1 Delta utility=0.0338683Task task422 pri=2 time=150 bldg=2 level=1 Delta utility=0.0336683Task task412 pri=3 time=150 bldg=2 level=1 Delta utility=0.038629Task task22 pri=5 time=150 bldg=2 level=1 Delta utility=0.0481505

NPT Factor: For this example, The NPT user-defined constant (multiplier)is 0.9. Note that Fred has 10 minutes of NPT: this is the distancebetween building 1 and building 2, according to the configuration filefor that site. Therefore his NET is derived as follows:

NPT=(pt−npt*UserNPTFactor)/pt

Fred's schedule includes 8 hours (800 hundredths) productive time and 10hundredths of npt and user defined constant Factor=0.9. Therefore:

NPT=(800−(0.9*10)/900=(800−9)/800=791/800=0.98875

Grade Factor: The grade factor for this schedule is derived as follows:Fred's UserGradeFactor (multiplier) is 0.9 according to theconfiguration file. We first compute the rawGradefactor and then apply:

Grade factor=1−UserGradeFactor(1−rawGradeFactor)  (**)

The raw grade factor is the sum of (the time on productivejobs×penalty)/time on productive jobs. The time on productive jobs canbe seen is 8 hours (800 hundredths). The penalty is 1−(4#gradesover/maxGrades), where maxGrades is set to 5 in the configuration file.For the first task, time=50, penalty=(1−(4/5))=0.2 so time*penalty=10.Similarly, for the others the values are 10, 10, 10, 30, 30, 30, 30 fora total of 160, so the raw factor is 160/800 or 0.2.

We then apply the equation and compute the grade factor from (**) above:

Grade factor=1−(0.9*(1−0.20))=1−(0.9*0.8)=1−0.72=0.28

Thus the combined utility (the TRE scheduler rules determine that k=0.5in this example) is:

0.28*0.9975*raw utility

We now compute the raw utility. The raw utility is, for k=0.5,

0.5A+(1−0.5)B

A is % time on schedule, or 800/870=0.91954. B is % time*priority or(50*3+50*3+50*4+50*4+150*2+150*2+150*3+150*5)=2500/(870*5)=2500/4350=0.57471. Thus,

0.5A+(1−0.5)B=0.5(0.91954)+(1−0.5)0.57471=.45977+0.28736=0.7471

Therefore the final utility is:

0.28*0.98875*0.7471=0.20684

The system and method as described above includes a set of algorithmsthat schedule workers to jobs. These include a variety of initialscheduling algorithms (e.g., Round Robin) and a rescheduling algorithm(FIG. 14). The rescheduling algorithm is a “hill-climbing” algorithmthat swaps jobs between a worker and the Unassigned Job Queue, tomaximize the Utility function. This effectively allows the search(through the space of job assignments) to find a local maximum using thehill-climbing algorithm.

Additionally, the algorithms as described all include a constraint-basedfilter that determines whether a worker was eligible for a job, forexample, the worker must have the skill that the job requires and atleast the skill level the job requires. The worker should belong to anorganization if the job is restricted to that organization. However,these constraints were not used to direct the original schedulingalgorithm or the rescheduling algorithm. The constraints were not usedto determine the next “move” in the search space that these algorithmsrepresented.

The system, in accordance with non-limiting examples, includes fourextensions to these scheduling algorithms. An extension includes theaddition of meta-heuristics to guide the rescheduling algorithm so thatit does not get stuck at a local maximum. This allows the scheduler tobetter solve problems that are described by a solution surface that hasmany local maxima, which is true of most worker scheduling problems.

Another extension also includes the explicit representation ofconstraints and Utility as objects to be used in the schedulingalgorithms. This allows new constraints and utility factors (penaltyfactors) to be introduced to the scheduler in a timely fashion,including having them being defined by program code (and therefore notrequiring that they be defined in advance by a programmer).

Yet another extension includes the addition of a constraint-directedcomponent to the choice of which move to try next in the hill-climbingalgorithm. This allows the scheduler to handle problems with severalconstraints and complex constraints, such as those that are required forhandling resources.

Still yet another extension includes the use of these features to extendthe scheduler to include considerations of (non-sharable, reusable)resources and wall-clock time. This allows new domains to be scheduled,such as those that require workers to work jobs at specific times (e.g.,a lecture that must be attended at 10:00 AM) and to include reasoningabout scarce resources (e.g., cranes that are required by some jobs butnot others where there may be more jobs to be scheduled simultaneouslythan there are cranes available). The rest of this document describesthese four features in more detail.

Meta-heuristics are algorithms (heuristics) that are used to control alocal search. They are typically generic. They are applicable to severaldomains and are configurable to be used in a given domain. Generalpurpose heuristic methods are used to guide a local search algorithm,such as the hill-climbing algorithm, towards high-utility portions ofthe search space. They are used in accordance with one non-limitingexample to control the hill-climbing algorithm and focus it on regionsof the search space that include moves to schedules that are of highutility.

FIG. 18 shows an example of a surface that has several local maxima. Itis not readily apparent which of these is a global maximum.

FIGS. 19A and 19B show examples of a search space with two exhaustivesearch techniques, depth-first and breadth-first searching and indicatedby the search levels and search objects listed A, B and C. The scheduleruses a local search guided by constraints instead of one of theseexhaustive search techniques.

Each type of meta-heuristic includes a mechanism to escape from localmaxima. For example, Iterated Local Search escapes from a local maximumby perturbing (in a principled way) the solution found (the localmaximum) and then using it as the starting point for a new local search.A variable Neighborhood Search enlarges the neighborhood used insuccessive local searches, which makes other maxima reachable insubsequent searches.

There are several meta-heuristics that are applicable in this domain andthat will be used to control the scheduling hill-climbing algorithm.These include the various searches that are explained.

1) Tabu Search. This meta-heuristic will be used to keep the search fromreturning to recently explored portions of the search space, by keepinga “tabu list” of such moves. It will use an aspiration criteria thatallows such a move if it results in a set of schedules that have higherutility than any such set previously seen. Memory will be used as wellto implement intensification strategies (to explore in more detailportions of the search space that show promise) and diversificationstrategies (to explore at least to some extent regions of the searchspace that have not yet been visited).

2) Iterated Local Search. This meta-heuristic runs the hill-climbingalgorithm, and then perturbates the solution found, using this newsolution as the starting value for another hill-climbing algorithm, andrepeats this process until a termination condition (e.g., number ofiterations, negligible changes in the returned value from one iterationto the next) holds.

3) Guided Local Search. This meta-heuristic runs the hill-climbingalgorithm, and then perturbates the utility function used, penalizingcomponents of the solution that are sub-optimal. It does this bydetermining a set of features that should be satisfied in the solution(e.g., minimizing non-productive time) and giving those that are notsatisfied in the present solution more weight in the utility functionduring the next iteration. It does this until a termination conditionholds (e.g., number of iterations, negligible changes in the returnedvalue from one iteration to the next). The approach takes advantage ofthe fact that a local optimum of the hill-climbing algorithm for oneUtility function may be different than the local optimum generated fromthe same data (workers, jobs) using a modified Utility function.

4) Variable Neighborhood Search. This meta-heuristic runs thehill-climbing algorithm, and then perturbates the neighborhood to beused in the next iteration. It begins with a restricted neighborhood forthe first iteration and uses the results of the iteration to determine asomewhat less restricted neighborhood for the next iteration, whichimplements a diversification strategy. It does this until a terminationcondition holds (e.g., number of iterations, negligible changes in thereturned value from one iteration to the next).

As noted above, the system can be a process of using a rule-engine tomap from the problem space (workers, jobs, etc.) to the solutionapproach (determination of the initial scheduling algorithm and therescheduling algorithm to be used and their parameters). This CIPincludes using the rule engine to determine which meta-heuristic(s) touse and the parameters to be used for them. An example of such a rulewould be:

IF: The ratio of jobs to workers is >Min_Ratio;AND: There are no jobs that require more than one worker;AND: Each worker has only one skill;THEN: Use Tabu search, with a tabu tenure of 2

This tabu search would keep a tabu list where each entry would be thenegation of the last move. For example, if the move removed job X fromworker Y's schedule and added it to worker Z's schedule, then the tabulist would include an element (ADD X Y) and an element (REMOVE X Z). The“tabu tenure” indicates for how many cycles of local search the move isnot allowed. Thus, in this case, the system ensures that any move (suchas adding the job to worker Z) is not undone for this many moves.

The Tabu search example also shows the use of intensification anddiversification. Intensification is applied by returning to a bestsolution so far if no improvement has taken place for a given number ofiterations. The algorithm assumes there is a counter for the iterationsof local search, and a numerical maximum, Int, for the number ofiterations to be done without improvement before intensification takesplace.

IF: No improvement found in best solution in last Int solutionsTHEN: Reset solution to best found so far,

Reset Intensification counter to 0,

-   -   Continue local search

Diversification is applied by restarting the search from a new randomassignment if no feasible solution found for a number of iterations. Thealgorithm assumes there is a numerical maximum, Div, for the number ofiterations to be done without improvement before diversification takesplace:

IF: No improvement found in best solution in last Div solutionsTHEN: Reset solution to random solution,

Reset Diversification counter to 0,

Continue local search

Constraints and utility can be used in the scheduling algorithm. Thearchitecture enforces a separation of the definition of the model(workers, jobs, skills, locations, constraints, utility function) fromthat of the search strategy (initial scheduling algorithm, local-searchrescheduling algorithm, meta-heuristic). This allows the searchprocedure to be developed as a generic search, which instantiatesspecific initial scheduling algorithms, local search algorithms, andmeta-heuristics, based on the outputs of the rule engine that maps fromthe problem space to the solution approach (as described in the originalpatent and updated to set the type and parameters for themeta-heuristic).

Each constraint object will contain the following capabilities:

1) A function that returns whether the constraint is satisfied.

2) A function that returns the degree to which a constraint is notsatisfied.

3) A function that returns the delta between the degree to which theconstraint is not satisfied using the present assignments of jobs toworkers and the degree to which the constraint would not be satisfied ifone or more additional assignments were to be made.

4) A function that returns the delta between the degree to which theconstraint is not satisfied using the present assignments of jobs toworkers and the degree to which the constraint would not be satisfied ifone or more of these assignments were to be changed (e.g., using a movein the hill-climbing algorithm).

Similarly, each utility object will contain the following capabilities:

1) A function that returns the value of the overall utility of thepresent set of (worker, job) assignments.

2) A function that returns the delta between the overall utility usingthe present assignments of jobs to workers and the overall utility ifone or more additional assignments were to be made.

3) A function that returns the delta between the overall utility usingthe present assignments of jobs to workers and the overall utility ifone or more of these assignments were to be changed (e.g., using a movein the hill-climbing algorithm).

Constraints in the scheduler include both numerical constraints andcombinatorial constraints. An example of a numerical constraint would be“The sum of the hours of the jobs on the schedule must not exceed thehours on the schedule.” An example of a combinatorial constraint wouldbe “A worker can only have one skill level for a given skill (e.g.,cannot be both a junior and a senior electrician)”.

For example, the constraint that represents “The sum of the hours of thejobs on the schedule must not exceed the hours on the schedule.” wouldbe encapsulated in an object that would check the number of hours on theworker's schedule and the number of hours for the jobs (plus thenon-productive time).

1) The function (function 1) that returns whether the constraint issatisfied checks whether the job time+non-productive time is less thanor equal to the worker's time available.

2) The function (function 2) that returns the degree to which aconstraint is not satisfied would then return the worker's time minusthe total of job time and non-productive time.

3) The function (function 3) that returns the delta between the degreeto which the constraint is not satisfied using the present assignmentsof jobs to workers and the degree to which the constraint would not besatisfied if one or more additional assignments were to be made wouldreturn the difference between function 2 as applied to the original mixof jobs and function 2 as applied to the new mix of jobs (with theadditional assignments).

4) The function (function 4) that returns the delta between the degreeto which the constraint is not satisfied using the present assignmentsof jobs to workers and the degree to which the constraint would not besatisfied if one or more of these assignments were to be changed wouldreturn the difference between function 2 as applied to the original mixof jobs and function 2 as applied to the new mix of jobs (with thechanged assignments).

These constraint and utility objects may be coded in a general-purposehigh-level language (such as Java) or using one of the search-orientedmodeling languages that are becoming available.

Constraints can be used to direct the search. These constraint andutility objects will be used by the rescheduling (hill-climbing, localsearch) algorithms and the meta-heuristics as part of their searchstrategy. Thus, for example, the present rescheduling algorithm tries toswap jobs between a worker and the unassigned job queue, selecting theone that gives the best delta utility between the present assignmentsand the swapped assignments. In the constraint-directed search, thevalue of each such move is determined by calling the utility function'sthird function mentioned above, subject to the level of constraintviolations determined by using the constraint objects fourth method.That is to say, the rescheduling and meta-heuristic components arewritten using these functions instead of calculating any constraintviolations or utility values by hand, as is done in the original system.

These algorithms can continue to be coded in a general-purpose highlevel language (such as Java) or may be coded in one of the emerginglanguages for search. The heart of this procedure is to be able toefficiently determine how all constraints and utility functions changeas variable assignments change, which can be optimized based on buildinga (pre-compiled) map that shows the transitive closure of the effect ofa given variable assignment on other variables.

As an example, the constraint that represents “The sum of the hours ofthe jobs on the schedule must not exceed the hours on the schedule”would be used to direct the search away from assignments that violatethe constraint. This would be done by searching for assignments that aresimilar to the one being considered but do not violate this constraint(and other constraints).

Resources and wall clock time can be implemented. Implementingnon-sharable, reusable resources is based on keeping track of the usageof the resource in each time period (the resource profile) andimplementing constraints to represent any violations on the use of theresource. Thus, for example, if a resource can have six simultaneoususers (or there are a set of six identical single-user resources to beused) and if time is quantized (see below) into five minute intervals,then a Constraint object is defined for this resource that shows amaximum allowable use of 6 and the Constraint functions defined aboverespect the fact that no more than six of these can be allocated in anyquantum of time. The penalty value may be set differently for differenttypes of resources, using the above-mentioned mechanisms.

Implementing wall-clock time is done by quantizing time into chunks(e.g., 5 minutes), which is used in support of the resource constraintsdescribed above. It also allows the modeling language to includeconstructs that restrict the scheduling of jobs to using a set ofrelationships that extend the capability to describe the temporalrelationship between different jobs. The original patent defined theprecedes relationship “job x must finish before job y may start”. ThisCIP defines other types of relationships may hold, amongst others:

1) Job x and job y may not overlap (but may be sequenced either with xpreceding y or y preceding x).

2) Job x must finish at least z quanta of time before job y starts.

Additionally, constraints may be placed on the start or end time ofindividual jobs. These relationships include:

1) Job x must start at a given time.

2) Job x must not start until at least a given time.

3) Job x must end at a given time.

4) Job x must end by a given time.

Resource profiles are examples of complex constraints. The idea is that,at the time that a job is to start, the resource profile will beexamined to ensure that no resources are being excessively allocated.That is, the allocation of the resource to jobs that are scheduled atthe same time must not exceed the available amount of the resource. Anexample of a resource usage profile is shown in FIG. 20. Note that,according to this figure, the resource is being over-allocated for partof the scheduled time.

Many modifications and other embodiments of the invention will come tothe mind of one skilled in the art having the benefit of the teachingspresented in the foregoing descriptions and the associated drawings.Therefore, it is understood that the invention is not to be limited tothe specific embodiments disclosed, and that modifications andembodiments are intended to be included within the scope of the appendedclaims.

1-20. (canceled)
 21. A system for managing mobile workers, comprising: aserver; a database associated with the server and having a plurality oftarget objects that are classified corresponding to facilities assets tobe worked on by a mobile worker, and attributes of each target object,including any tasks to be performed on target objects; a rule engineoperative for determining algorithms based on a utility function forpartitioned jobs and mobile workers wherein different algorithms areselected and used for different partitions to schedule jobs and mobileworkers in selected different regions, wherein an algorithm is selectedbased on a weighted sum that is calculated from a possible number ofwork schedules, jobs and mobile workers for each partition, wherein aselected policy for a job environment determines how mobile workers,jobs and work schedules are partitioned; and a plurality of systemagents that automate supervision including work planning, scheduling,dispatching, stores management, job state management and end-of-shiftmanagement.
 22. The system according to claim 21, wherein said serverfurther comprises a simulator database and simulation module thatqueries the simulator database to determine the effects of a policychange on planning and scheduling of jobs and workers using differentalgorithms and partitions.
 23. The system according to claim 21, whereinsaid server further comprises an event bus operative with the systemagents and database, wherein said system agents communicate across theevent bus with the database and rule engine for implementing systemagent functions based on events passed over the event bus.
 24. Thesystem according to claim 21, and further comprising a schedulingalgorithm configured to map from a problem space for partitioned jobsand mobile workers to a solution to schedule jobs and mobile workers inselected different regions.
 25. The system according to claim 24,wherein the scheduling algorithm is operative with numerical andcombinatorial constraint objects allowing searching from a generalsearch to a more specific search.
 26. The system according to claim 25,and further comprising a constraint object for maintaining time usage ofa constraint object.
 27. The system according to claim 24, wherein saidscheduling algorithm comprises a rescheduling algorithm.
 28. The systemaccording to claim 24, wherein the rule engine is operative to controlthe scheduling algorithm using heuristics comprising at least one of atabu search, iterated local search, guided local search and variableneighborhood search.
 29. The system according to claim 28, wherein saidtabu search is operative to prevent searching recently explored portionsof the search space.
 30. The system according to claim 28, wherein saiditerated local search perturbates a solution for a new solution as astarting value for another scheduling algorithm.
 31. The systemaccording to claim 28, wherein said guided local search perturbates autility function to penalize sub-optimal components of a solution. 32.The system according to claim 28, wherein the variable neighborhoodsearch perturbates a neighborhood search to be used in a next iteration.33. A system for managing mobile workers, comprising: a server; adatabase associated with the server having a plurality of target objectsthat are classified corresponding to facilities assets to be worked onby a mobile worker, and attributes of each target object, including anytasks to be performed on target objects; a rule engine operative fordetermining algorithms based on a utility function for partitioned jobsand mobile workers wherein different algorithms are selected and usedfor different partitions to schedule jobs and mobile workers in selecteddifferent regions, wherein an algorithm is selected based on a weightedsum that is calculated from a possible number of work schedules, jobsand mobile workers for each partition, wherein a selected policy for ajob environment determines how mobile workers, jobs and work schedulesare partitioned; and a plurality of system agents that automatesupervision including work planning, scheduling, dispatching, storesmanagement, job, state management and end-of-shift management.
 34. Thesystem according to claim 33, wherein said server further comprises asimulator database and simulation module that queries the simulatordatabase to determine the effects of a policy change on planning andscheduling of jobs and workers using different algorithms andpartitions.
 35. The system according to claim 33, wherein said serverfurther comprises an event bus operative with the system agents anddatabase, wherein said system agents communicate across the event buswith the database and rule engine for implementing system agentfunctions based on events passed over the event bus.
 36. The systemaccording to claim 33, and further comprising a scheduling algorithmconfigured to map from a problem space for partitioned jobs and mobileworkers to a solution to schedule jobs and mobile workers in selecteddifferent regions.
 37. The system according to claim 36, wherein thescheduling algorithm is operative with numerical and combinatorialconstraint objects allowing searching from a general search to a morespecific search.
 38. The system according to claim 37, and furthercomprising a constraint object for maintaining time usage of aconstraint object.
 39. The system according to claim 36, wherein saidscheduling algorithm comprises a rescheduling algorithm.
 40. The systemaccording to claim 36, wherein the rule engine is operative to controlthe scheduling algorithm using heuristics comprising at least one of atabu search, iterated local search, guided local search and variableneighborhood search.
 41. The system according to claim 40, wherein saidtabu search is operative to prevent searching recently explored portionsof the search space.
 42. The system according to claim 40, wherein saiditerated local search perturbates a solution for a new solution as astarting value for another scheduling algorithm.
 43. The systemaccording to claim 40, wherein said guided local search perturbates autility function to penalize sub-optimal components of a solution. 44.The system according to claim 40, wherein the variable neighborhoodsearch perturbates a neighborhood search to be used in a next iteration.